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REMARKS 

This Amendment is filed in response to the FINAL Office action mailed August 
26, 2005. All objections and rejections are traversed. 

Claims 1 to 4 and 9 to 35 are in the application and currently pending. 

Claims 26, 27, 33, and 34 are currently amended to overcome objections. 

Allowable Subject Matter 

Claims 26 and 33 were objected to as being dependent upon a rejected base claim. 

Claims 26 and 33 have been amended into independent form and are believed to 
be allowable. 

35 U.S.C. §112 

At page 2 of the Office Action, claims 27 and 34 were rejected under 35 U.S.C. 
§1 12 as failing to comply with the written description requirement and as being indefi- 
nite. 

Claims 27 and 34 are amended to overcome the rejection. 
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35 U.S.C. §103 

At page 3 of the Office action claims 1-3 and 9-16 were rejected under 35 U.S.C. 
§ 103 as being unpatentable over Martin et al., US Patent No. 6,765,927, issued July 20, 
2004, hereinafter Martin, in view of "Real-Time Streaming Protocol", Request for com- 
ment 2326, April 1998, hereinafter RFC 2326. 

The present invention, as set forth in representative claim 1, comprises in aprt: 

1 . An intermediate network device for use within a computer network hav- 
ing a server configured to provide one or more data streams to a client, 
each stream having a corresponding bandwidth, the network device com- 
prising: 

means for determining network traffic characteristics sufficient to 
identify a stream from the server to the client; 

a packet classification engine for snooping on Real Time Stream- 
ing Protocol (RTSP) messages for determining the bandwidth of the 
stream; and 

a resource reservation protocol (RS VP) transmitter proxy config- 
ured to reserve resources within the computer network on behalf of the 
server for allocation to the stream. 



By way of background, Martin describes a Resource Reservation protocol 
(RSVP) host proxy service. A switch provides the RSVP proxy service for an RSVP- 
unaware source. The RSVP- unaware source transmits packets with headers and the 
switch reads the headers for information to use in a RSVP protocol. 

RFC 2326 describes the Real Time Streaming Protocol (RTSP). RTSP is an ap- 
plication-level protocol for control over the delivery of data with real-time properties. 
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Applicant respectfully urges that Martin and RFC 2326 do not show Applicant's 
novel a packet classification engine for snooping on Real Time Streaming Protocol 
(RTSP) messages for determining the bandwidth of the stream. 

Nowhere does Martin determine the bandwidth of the stream from the headers 
because the headers do not contain information to determine the actual bandwidth 
needed. In further detail, the Tspec header in Martin describes the resources that should 
be reserved. (Col. 5, lines 23-30). 

The Examiner argues that Martin at Col.3, lines 23-26 and Col. 5, lines 1-5 de- 
scribes a packet classification engine for determining the bandwidth of the stream. 

Col. 3, lines 23-26 states: 

"Edge switch 140 receives the data packet, determines that the data packet 
meets RS VP sender host proxy criteria, generates an RS VP Path message 
in accordance with an RSVP sender host function, modifies certain fields 
of the RSVP Path message if required in accordance with an RSVP router 
function, and transmits the RSVP Path message on backbone network 
130." 



Col. 5, lines 1-5 states: 

"RSVP Path message 330 includes an RSVP common header identifying 
the message as a Path message and an RSVP object including the contents 
of the Path message. The contents of the Path message include a Sender 
TSPEC describing the flow the sender expects to generate and an 
ADSPEC. The Sender TSPEC traverses the flowpath from the RSVP 
sender to the RSVP receiver without modification, whereas the ADSPEC 
may be modified by switches along the flowpath to indicate the availabil- 
ity of QoS control services and parameters required for QoS control ser- 
vices to operate correctly." 
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In reference to the above statements, Martin is silent concerning determining the 
actual bandwidth of the stream. The cited art describes using a switch to determine an 
approximate bandwidth based on RSVP request messages. In sharp contrast, Applicant's 
invention determines the actual bandwidth as determined by snooping. Furthermore, Ap- 
plicant's invention prevents too much bandwidth from being reserved, or congestion de- 
veloping because not enough bandwidth is reserved. 

The Examiner argues that RFC 2326 at abstract and two paragraphs above Ap- 
pendix A describes stream control. 

Abstract states: 

"The Real Time Streaming Protocol, or RTSP, is an application-level pro- 
tocol for control over the delivery of data with real-time properties. RTSP 
provides an extensible framework to enable controlled, on-demand deliv- 
ery of real-time data, such as audio and video. Sources of data can include 
both live data feeds and stored clips. This protocol is intended to control 
multiple data delivery sessions, provide a means for choosing delivery 
channels such as UDP, multicast UDP and TCP, and provide a means for 
choosing delivery mechanisms based upon RTP (RFC 1889)." 



Two paragraphs above Appendix A states: 
"Stream issues: 

RTSP only provides for stream control. Stream delivery issues are 
not covered in this section, nor in the rest of this memo. RTSP implemen- 
tations will most likely rely on other protocols such as RTP, IP multicast, 
RSVP and IGMP, and should address security considerations brought up 
in those and other applicable specifications." 



"12.6 Bandwidth 

The Bandwidth request header field describes the estimated bandwidth 
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available to the client, expressed as a positive integer and measured in bits 
per second. The bandwidth available to the client may change during an 
RTSP session, e.g., due to modem retraining." 

In reference to the above statements, RFC 2326 is silent concerning using the 
messages to determine the actual bandwidth. The above statements describe reading 
header fields to estimate bandwidth. Applicant's invention claims determining the band- 
width based on the actual messages to find the actual bandwidth necessary to send the 
messages. 

In Martin or RFC 2326 the estimate of bandwidth can be inefficient. With the es- 
timate based on message requests, there is a strong possibility too much bandwidth may 
be reserved when messages are not sent. Additionally, if enough bandwidth is not re- 
served, congestion can occur as messages are sent. 

Applicant respectfully urges that the Martin patent and RFC 2326 either taken 
singly or taken in combination are legally precluded from rendering the presently claimed 
invention obvious under 35 U.S.C. §103 because of the absence in each of the cited pat- 
ents of Applicant's claimed novel a packet classification engine for snooping on Real 
Time Streaming Protocol (RTSP) messages for determining the bandwidth of the 
stream. 
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At page 7 of the Office Action claim 4 was rejected under 35 U.S.C. §103 as be- 
ing unpatentable over Martin, in view of Resource ReSerVation Protocol (RSVP), RFC 

1 

2205. 



Applicant respectfully notes that claim 4 is a dependent claim that depends from 
independent claim 1, which is believed to be in condition for allowance. Accordingly 
claim 4 is believed to be in condition for allowance. 



At page 7 of the Office Action claims 17-19 were rejected under 35 U.S.C §103 
as being unpatentable over Martin, in view of "Format of the RSVP DCLASS Object", 
Request For Comments 2996, published November 2000, hereinafter RFC 2996. 

The present invention, as set forth in representative claim 17 comprises in part: 

17. An intermediate network device for use within a computer network 
having a server configured to provide one or more data streams to a client, 
each stream having a corresponding bandwidth, the intermediate network 
device comprising: 

means for determining traffic characteristics sufficiently to identify 
a stream from the server to the client; 

means for determining the bandwidth of the stream; 

a resource reservation protocol (RSVP) transmitter proxy config- 
ured to reserve resources within the computer network on behalf of the 
server for allocation to the stream and to generate and send one of more 
RSVP Path messages on behalf of the server, the one or more RSVP Path 
messages containing the network traffic characteristics and the bandwidth 
of the stream, and means for obtaining a differentiated services codepoint 
(DSCP) value that is based on the bandwidth of the stream. 
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By way of background, RFC 2996 describes using a resource Reservation Proto- 
col to handle request for Quality of Service. The system is based in a differentiated ser- 
vice (DS) network. Using RSVP with DS networks allows the RSVP message objects to 
carry Differential Service Code Points (DSCPs) 

Applicant respectfully urges that Martin or RFC 2996 do not show Applicant's 
novel means for determining the bandwidth of the stream. Martin and RFC 2996 are 
silent concerning determining the actual bandwidth necessary from the RSVP messages. 

Applicant respectfully urges that the Martin patent and RFC 2996 either taken 
singly or taken in combination are legally precluded from rendering the presently claimed 
invention obvious under 35 U.S.C. §103 because of the absence in each of the cited pat- 
ents of Applicant's claimed novel means for determining the bandwidth of the stream. 

At page 9 of the Office Action, claims 20-25, 27, 29-32, and 34 were rejected un- 
der 35 U.S.C. §103 as being unpatentable over Martin, in view of Merwe et al., 
"mmdump: A Tool for Monitoring Internet Multimedia Traffic", 2000, hereinafter 
Merwe. 

The present invention, as set forth in representative claim 20 comprises in part: 

20. A method for providing one or more data streams from a server to a 
client, each stream having a corresponding bandwidth, the method com- 
prising: 

receiving a message from a client to a server, 
determining network traffic characteristics sufficient to identify a 
stream from the server to the client; 
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determining the bandwidth of the stream ; and 
sending via a resource reservation protocol (RS VP) transmitter 
proxy, messages to nodes along a data path from the server to the client to 
reserve resources within the computer network on behalf of the server for 
allocation to the stream. 

By way of background, Merwe describes a system using a Real Time Streaming 
Protocol (RTSP). The RTSP is used to set up and control the playback of streaming con- 
tent across the internet. A client may issue a DESCRIBE command request for a particu- 
lar media stream. The response from the server contains specific information about the 
stream, e.g., the encoding used, the clip length, and the average bit rate. Furthermore, the 
estimated bandwidth set up to send streaming content is determined by packet arrival 
times and a probe point. 

Applicant respectfully urges that Martin and Merwe do not show Applicant's 
claimed novel determining the bandwidth of the stream. Applicant claims the band- 
width is determined based on the actual RSVP messages that will be sent. By determin- 
ing the actual bandwidth, the system is more efficient. In contrast, Merwe only describes 
an estimated bandwidth based on packet arrival times and a probe point. Furthermore, 
Martin estimates the bandwidth on RSVP request messages. Neither Martin nor Merwe 
describe determining the bandwidth based on actual messages. 

Applicant respectfully urges that the Martin patent and Merwe either taken singly 
or taken in combination are legally precluded from rendering the presently claimed in- 
vention obvious under 35 U.S.C. §103 because of the absence in each of the cited patents 
of Applicant's claimed novel determining the bandwidth of the stream. 
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At page 1 1 of the Office Action claims 28 and 35 were rejected under 35 U.S. C. 
§103 as being unpatentable over martin, in view of Merwe, and in further view of Gai et 
al, "RSVP Proxy - Internet Draft", hereinafter Gai. 

Applicant respectfully notes that claims 28 and 35 are dependent claims that de- 
pend from independent claims, which are believed to be in condition for allowance. Ac- 
cordingly claims 28 and 35 are believed to be in condition for allowance. 

All independent claims are believed to be in condition for allowance. 

All dependent claims are believed to be dependent from allowable independent 
claims, and therefore in condition for allowance. 

Favorable action is respectfully solicited. 

Please charge any additional fee occasioned by this paper to our Deposit Account 



No. 03-1237. 



Respectfully submitted, 




Reg. No. 51,605 

CESARI AND MCKENNA, LLP 
88 Black Falcon Avenue 
Boston, MA 02210-2414 
(617) 951-2500 
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